REMARKS 

Claims 1-6, and 8-9 are pending in the present application and stand rejected. 
Claim 4 has been amended. The Examiner's reconsideration is respectfully requested in 
view of the following remarks. 

Amendment to the Specification 

Applicants respectfully disagree with the Examiner's assertion that the amendment 
filed on 7/24/2006 contains new matter. The Examiner should note that a determination of 
"new matter" is not based solely on a lack of verbatim description, but rather, what is 
disclosed in the specification, claims, and drawings as a whole. Here the amendments are 
fully supported by the original disclosure, including the specification, the claims and the 
drawings as a whole. 

The prior amendment to page 10, line 10- page 1 1, line 3 is not new matter because 
FIG. 1 and more specifically, element 101 of FIG. 1 , page 3, lines 1 5-20, and page 1 0, lines 
24-26 teaches a service engine having a queue manager which supports asynchronous 
requests based on a queue and a session manager which supports synchronous requests 
based on a session. It is generally known in the art, at the time of the invention, that a 
queue manager may manage one or more queues and a session manager may manage one 
or more sessions. Further, the originally filed claim 4 shows that asynchronized requests 
may be based on a queue and synchronized requests may be based on a session. This 
means that asynchronized requests are essentially managed by a queue and synchronized 
requests are essentially managed by a session. Accordingly, applicants assert that 
asynchronized requests managed by a queue and synchronized requests managed by a 
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session are fully supported by the disclosure. In any event, applicants have amended the 

specification, listed as the first amendment above, to clarify the corresponding 

management roles of the queue and session managers. 

With respect to the second proposed amendment, through a typographical error, 

lines 9-11 inadvertently referenced FIG. 4 and lines 12-14 inadvertently referenced FIG. 5. 

This is glaringly obvious by a quick examination of FIGSs. 4 and 5, which clearly shows 

this error, and the above amendment is essentially a swapping of those lines. This 

amendment also includes the replacement of "service abstraction layer (platform-service 

interface) with "service abstraction layer (service-platform interface), which was 

previously objected to by the Examiner in paragraph 3, page 2 of the Final Office Action. 

The Examiner objects to this change as an attempt to establish a relationship between 

service abstraction layer (SAL) and service-platform layer that never existed before. This 

is incorrect because such a relationship was always present. The term "service-platform 

interface" is present in FIG. 4 as the title of FIG. 4 and lines 9-1 1 of the amended 

specification, as originally intended, states that FIG. 4 shows the Service Abstraction 

Layer. From this, one can clearly see that the terms 'service' and 'platform' were 

inadvertently swapped and the amendment merely aims to correct this error which is 

consistent with the scope of the disclosure. 

The Examiner also objects to the previous amendment of page 9, line 19-page 1.0, 

line 2, as constituting new matter. Specifically, the Examiner objects to the bolded portion 

of the following statement: 

After getting the data from the backend system through the platform kernel, the 
device gateway then transforms an XML response returned by the platform 
kernel section into a device readable page by transforming the XML response 
into a file format which is adapted for the device and transforming among 
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communication protocols based on script languages of the device and sends the 
page to the device over the network 

This is incorrect because the statement in its entirety is fully supported by 
Applicant's specification. The device-platform interface is defined on page 6, lines 9-1 1 of 
Applicant's specification to be the device abstraction layer which receives XML responses 
returned by the platform kernel section as illustrated by the arrow labeled XML in FIG. 1 
between the service engine 101 and the device abstraction layer. Further, page 9, lines 19- 
22 of Applicant's specification states the gateway is in the device abstraction layer and 
transforms the page (i.e., XML page or response) into a device readable page. 

In any event, for purposes of cooperation. Applicants have amended the 
specification, listed above as the third amendment, to directly include portions of text, from 
claim 6. 

Claim Rejections - §112 

Claim 1 was rejected under 35 U.S.C. §112, first paragraph, as failing to comply 

with the written description requirement. In particular, on page 3 of the Final Office 

Action, the Examiner states the following: 

[Applicants disclosure never describes "a device-platform interface, for accepting 
device requests issued by devices wherein said device requests are in a device 
specific format, transforming the device requests into XML request and then 
sending the XML requests to a platform kernel section, and transforming XML 
responses which are returned by the platform kernel section into the device specific 
format". 

Again,- the basis for this finding is erroneously derived from the Examiner's 
mistaken belief that there must be a verbatim description between claim s and disclosure to 
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satisfy 1 12, written description. However, the specification is wholly replete with 
disclosure to support the subject matter of claim 1. 

The device-platform interface is described on (page 6, lines 9-11 of Applicant's 
specification) to be the device abstraction layer. Page 2, lines 21- page 3, line 2 states the 
device abstraction layer "accepts requests from devices and transforms them into XML and 
then sends them to the kernel of the platform" and "transforms the response XM L 
documents from the platform into a device specific format for presentation". Page 9, lines 
19-22 of Applicant's specification states that the device gateway sits in the device 
abstraction layer and that the device gateway accepts requests from a device over a 
network protocol and transforms the request into XML. and then sends the request to the 
platform kernel. 

So there is a disclosure of a device-platform interface accepting requests from a 
device because the gateway is in the device abstraction layer, which is defined as the 
device-platform interface. And it is implied that these device requests are in a device 
specific format (i.e., a format specific to that device) because the gateway is accepting 
requests directly from the device. Next, there is a disclosure of transforming the device 
requests into XML request because the gateway transforms the request into XML. Next, 
there is a disclosure of sending the XML requests to a platform kernel section because the 
gateway sends the request to the platform kernel. Further, there is a disclosure of 
transforming XML responses which are returned by the platform kernel section into the 
device specific format in FIG. 1, page 9, line 23 - page 10 lines 1-3, and page 2, line 24- 
page 3, line 2. Specifically, there is a an arrow labeled "XML" which shows XML 
requests being transferred from the service engine (defined on page 10, lines 1 5-16 to be 
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part of the platform kernel) to the DAL. Further, page 9, line 23 - page 10 lines 1 -? 
discloses after getting the data from the platform kernel, the gateway transforms a page 
into a device readable page to be sent to the device. In addition, page 2, lines 21 - page 3, 
line 2 discloses that the device abstraction layer transforms response XML documents 
from the platform into a device specific format. 

Accordingly, since there is support in Applicant's specification for the above claim 
language, the 1 1 2 rejection for claim 1 should be reversed. 

Claim 4 has been amended to restore the claim as originally filed. The specification 
has been amended to address the 1 12 rejection, and is listed as the first amendment above. 

Claim Rejections - §102 

Claims 1-2, 4, 6, and 8-9 stand rejected under 35 U.S.C. §102 as being anticipated 
by Lonroth. Applicants respectfully submit that at the very least, Lonroth is legally 
deficient to establish a prima facie case of anticipation against claim 1 . Specifically, 
Lonroth does not teach or suggest a platform kernel section for managing user 
information, device information and service information, as essentially recited inter alia, in 
claim 1 . 

The Examiner states that Lonroth teaches a platform kernel section for managing 
user information, device information and service information on col. 6, line 1- col. 7, line 
36, It is respectfully reminded that the Examiner has the burden to establish anticipation 
by showing how Lonroth discloses each and every limitation in the claims. The Examiner 
has recited over a hundred lines of text without any analysis of the claims. 
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It is not the Applicant's burden to show why Lonroth does not anticipate the 
claims. In any event, it is respectfully submitted that Examiner's characterization of the 
teachings of Lonroth is misplaced. The cited lines teach an XML processor 24.2. So it is 
assumed that the Examiner is suggesting the cited lines teach the XML processor 242 to be 
the platform kernel section for managing user, device, and service information. Ho wever, 
this is not correct because col. 6, lines 1-8 teaches that the purpose of the XML processor 
242 is to receive XML request documents from the XML preprocessor 240, parse the 
document, and resolve unresolved links it encounters by making calls through one or more 
XML gateways. There is simply no mention in the cited lines of the management of user, 
device, or service information. Further, Applicants can not find anything in Lonroth which 
is equal to or equivalent to a platform kernel section for managing user, device, and service 
information. 

In addition, Lonroth does not teach or suggest, a platform kernel section providing 
one of a synchronized and an asynchronized service engine, as essentially recited inter 
alia, in claim 1 . The Examiner states Lonroth teaches a platform kernel section providing 
one of a synchronized and an asynchronized service engine in the same hundred plus lines 
that was previously cited as disclosing a platform kernel section for managing user, device, 
and service information, namely col. 6, line 1- col. 7, line 36. However, this is not correct 
because there is no mention in the cited lines or elsewhere in Lonroth of a platform kernel 
providing one of a synchronized and asynchronized service engine. 

Accordingly, for at least the reasons above, and those of the prior Appeal brief, 
Lonroth does not anticipate claim 1. Moreover, claims 2, 4, 6, and 8-9 are patentable over 
Lonroth at least by virtue of their dependence from claim 1 . 
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Claim Rejections - §103 

Claims 3 and 5 stand rejected under 35 U.S.C. 103(a) as being unpatentable over 
Lonroth. At the very least, claims 3 and 5 are patentable because they depend from claim 
1, which is not anticipated by Lonroth for the reasons stated above. Additionally, 
Applicants submit that Lonroth is patentable for the reasons presented in the prior Appeal 
brief. 

Conclusion 

In view of the foregoing remarks, it is respectfully submitted that all the claims 
now pending in the application are in condition for allowance. Early and favorable 

reconsideration is respectfully requested. 



Respectfully submitted, 
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